맨위로가기

유닉스 파일 시스템

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

유닉스 파일 시스템(UFS)은 파일의 종류를 일반, 디렉터리, 특수, 지명 파일로 구분하여 관리하며, 부트 블록, 슈퍼 블록, 아이노드, 데이터 블록 등의 구성 요소를 갖는다. UFS는 블록을 기본 단위로 파일을 할당하며, 아이노드에 저장된 색인 기법을 통해 파일 블록의 위치를 관리한다. 초기 유닉스 파일 시스템인 FS에서 발전하여 실린더 그룹 개념을 도입한 FFS(Fast File System)를 거쳐, 블록 크기 증가, 블록 하위 할당 등의 개선을 통해 성능과 효율성을 향상시켰다. BSD 계열 시스템, 상업용 유닉스 시스템, 리눅스, macOS 등 다양한 운영체제에서 구현되었으며, 각 시스템별로 UFS를 개선하여 사용하고 있다.

더 읽어볼만한 페이지

  • 유닉스 - 유닉스 시간
    유닉스 시간은 1970년 1월 1일 00:00:00 UTC부터 경과된 초를 나타내는 시스템으로, 컴퓨터 시스템에서 시간 저장 및 처리에 널리 사용되며 32비트 정수 표현 시 2038년 문제를 야기할 수 있고 64비트 정수로 해결 가능하며, 다양한 시스템에서 타임스탬프로 활용되지만 윤초 처리 차이로 UTC 시간과 완벽히 일치하지는 않는다.
  • 유닉스 - 유닉스 계열
    유닉스 계열은 유닉스 운영체제의 특징과 설계를 공유하는 운영체제들을 지칭하며, 유전적, 상표, 기능적 유닉스로 분류되고 macOS는 상표 유닉스이자 유전적 유닉스에 해당하며 리눅스는 기능적 유닉스의 대표적인 예이다.
  • 파일 시스템 - 부트 섹터
    부트 섹터는 시스템 부팅 코드를 담은 저장 매체의 특정 영역으로, 볼륨 부트 레코드(VBR)와 마스터 부트 레코드(MBR)로 나뉘며, BIOS는 이를 실행하고 UEFI는 부트로더를 직접 로드하지만 바이러스 공격에 취약하다.
  • 파일 시스템 - ZFS
    ZFS는 Jeff Bonwick 등이 설계하고 구현한 파일 시스템으로, 데이터 무결성, 스냅샷, RAID-Z 등의 기능을 제공하며, 썬 마이크로시스템즈에서 개발되어 OpenZFS 프로젝트를 통해 다양한 운영체제에서 사용된다.
유닉스 파일 시스템 - [IT 관련 정보]에 관한 문서
파일 시스템 정보
이름UFS (유닉스 파일 시스템)
개발자CSRG
소개 운영 체제4.2BSD
디렉터리 구조테이블
최대 파일 크기273 바이트 (8 ZiB)
최대 파일 이름 크기255 바이트
최대 볼륨 크기273 바이트 (8 ZiB)
기록된 날짜UFS1 및 UFS2: 마지막 접근 시간 (atime), 마지막 수정 시간 (mtime), 마지막 inode 변경 시간 (ctime), UFS2: inode 생성 시간 (birthtime)
날짜 범위UFS1: 1901년 12월 14일–2038년 1월 18일, UFS2: epoch로부터 64비트 부호 있는 정수 오프셋
날짜 해상도UFS1 및 UFS2: 나노초
운영 체제A/UX, 드래곤플라이BSD, FreeBSD, FreeNAS, NAS4Free, HP-UX, NetBSD, 리눅스, OpenBSD, illumos, 솔라리스, SunOS, Tru64 UNIX, 유닉스 시스템 V, Orbis OS 등

2. 파일 유형

UFS는 파일의 종류를 구분하여 관리한다. UFS에는 다음과 같이 4가지 파일 유형이 있다.


  • 일반 파일: 사용자 프로그램, 시스템 유틸리티 프로그램에 의해 입력된 정보를 포함하는 파일이다.
  • 디렉터리: 파일의 이름과 아이노드를 위한 포인터를 포함한다.
  • 특수 파일: 터미널이나 프린터와 같은 입출력 장치들의 접근을 위해 사용된다.
  • 지명 파이프: 지명 파이프이다.

2. 1. 일반 파일

사용자와 시스템 프로그램의 데이터를 저장하는 파일이다.[1]

2. 2. 디렉터리

UFS에는 4가지 파일 유형이 있는데, 그 중 하나가 디렉터리이다. 디렉터리는 파일 이름과 아이노드를 위한 포인터를 포함하며, 계층적인 구조를 가진다. 디렉터리 파일은 쓰기 보호 속성을 가진 일반 파일로서 파일 시스템만이 이 파일에 쓰기를 할 수 있고, 사용자 프로그램은 읽기만 할 수 있다.[1]

2. 3. 특수 파일

터미널이나 프린터와 같은 입출력 장치 접근에 사용된다.[1]

2. 4. 지명 파이프

지명 파이프는 프로세스 간 통신에 사용되는 특수한 파일이다.[1]

3. 구성 요소

UFS는 파일 시스템의 메타데이터와 실제 데이터를 저장하기 위한 다양한 구성 요소를 가진다.[1]


  • 부트 블록: 유닉스 커널을 적재하기 위한 프로그램이 저장되어 있다.
  • 슈퍼 블록: 파일 시스템을 기술하는 정보를 저장하며, 파일 시스템마다 하나씩 존재한다.
  • 아이노드: 파일이나 디렉터리에 대한 모든 정보를 가지고 있는 구조체이다.
  • 데이터 블록: 실제 데이터가 파일 형태로 저장되는 공간이다.


UFS 볼륨은 부트 블록을 위해 예약된 파티션 시작 부분의 몇몇 블록, 슈퍼 블록, 그리고 실린더 그룹의 모음으로 구성된다. 각 실린더 그룹은 슈퍼 블록의 백업 사본, 실린더 그룹 헤더, 여러 개의 아이노드, 여러 개의 데이터 블록을 포함한다.[1]

3. 1. 부트 블록

운영 체제를 시작하기 위한 부트스트랩 코드를 저장한다.[1] 유닉스 커널을 적재하기 위한 프로그램이 파일 시스템에 저장되어 있으며, 파티션의 처음 몇 블록은 부트 블록으로 예약되어 있다.[1]

3. 2. 슈퍼 블록

슈퍼 블록은 파일 시스템을 기술하는 정보를 저장하며, 파일 시스템마다 하나씩 존재한다. 슈퍼 블록에는 다음과 같은 정보들이 저장된다.[1]

  • 자료 구조
  • 파일 시스템의 크기
  • 블록의 수
  • 이용 가능한 빈 블록 목록
  • 빈 블록 목록에서 그 다음의 빈 블록을 가리키는 인덱스
  • 아이노드 목록의 크기
  • 빈 아이노드의 수
  • 빈 아이노드 목록
  • 빈 아이노드 목록에서 그 다음의 빈 아이노드를 가리키는 인덱스
  • 빈 블록과 빈 아이노드 목록들에 대한 록 필드들
  • 슈퍼 블록이 수정되었는지 나타내는 플래그
  • 파일 시스템의 이름
  • 디스크 이름


또한, 슈퍼 블록은 UFS 파일 시스템임을 식별하는 매직 넘버와 파일 시스템의 지오메트리 및 통계, 동작 튜닝 매개변수와 같은 중요한 숫자들을 포함한다.[1] 각 실린더 그룹에는 슈퍼 블록의 백업 사본이 존재한다.[1]

3. 3. 아이노드 (inode)

아이노드는 파일이나 디렉터리에 대한 모든 정보를 가지고 있는 구조체이다.[1] 각 아이노드는 0부터 시작하여 순차적으로 번호가 매겨진다.[2] 아이노드 0은 할당되지 않은 디렉터리 항목용으로 예약되어 있으며, 아이노드 1은 과거 유닉스 버전에서 불량 블록 파일의 아이노드였고, 그 다음은 루트 디렉토리의 아이노드(항상 아이노드 2)와 lost+found 디렉토리의 아이노드(아이노드 3)가 있다.[2]

디렉터리 파일에는 디렉터리의 파일 이름 목록과 각 파일과 관련된 아이노드만 포함된다.[2] 파일에 대한 모든 메타데이터는 아이노드에 있다.[2]

3. 4. 데이터 블록

파일의 실제 데이터가 파일 형태로 저장되는 공간이다.[1]

4. 파일 할당

UFS에서 파일은 블록 단위로 할당되며, 필요에 따라 동적으로 할당된다. 따라서 파일 블록들이 하드 디스크 상에 연속적으로 위치할 필요는 없다.

4. 1. 색인 기법

UFS에서 파일 할당은 블록을 기본 단위로 하여 필요할 때 동적으로 할당된다. 그러므로 파일 블록들이 하드 디스크 상에 연속적으로 있을 필요가 없다. 색인 기법을 통해 파일의 아이노드에 저장된 색인을 유지하여 파일 블록 위치를 관리한다. 아이노드는 3바이트 짜리 주소 13개, 또는 포인터로 구성된 39바이트 주소 정보 1개를 가진다. 처음 10개의 주소는 파일에서 맨 처음 10개의 데이터 블록을 가리킨다. 만약 파일이 블록 10개보다 크면 하나 이상의 간접 수준이 사용된다.

4. 2. 간접 블록

UFS에서 파일 할당은 블록을 기본 단위로 하여 필요할 때 동적으로 할당된다. 그러므로 파일 블록들이 하드 디스크 상에 연속적으로 있을 필요가 없다. 색인 기법을 통해 파일의 아이노드에 저장된 색인을 유지한다. 아이노드는 3바이트 짜리 주소 13개, 또는 포인터로 구성된 39바이트 주소 정보 1개를 가진다. 처음 10개의 주소는 파일에서 맨 처음 10개의 데이터 블록을 가리킨다. 만약 파일이 블록 10개보다 크면 하나 이상의 간접 수준이 사용된다.

5. 발전 과정

초기 유닉스에서 사용하던 파일 시스템은 단순히 ''FS''라고 불렸다. FS에는 부트 블록, 슈퍼 블록, inode군, 데이터 블록군만 존재했다. 초기의 유닉스에서 사용하던 작은 디스크에서는 이것으로 충분했지만, 기술의 진보와 함께 디스크 용량이 커지면서, inode가 있는 부분과 데이터 블록 사이를 헤드가 왕복하면서 발생하는 효율 저하 문제가 발생했다. BSD에서는 이를 최적화한 FFS(Fast File System)를 도입했는데, 이는 디스크를 작은 부분으로 나누어 각각에 inode와 데이터 블록을 배치하는 실린더 그룹 개념을 도입한 것이다.

5. 1. FFS (Fast File System)

마셜 커크 맥커식은 버클리 대학원생 시절, 디스크를 작은 덩어리로 분할하고 각 그룹에 자체 아이노드와 데이터 블록을 배치하는 실린더 그룹 개념을 도입하여 V7 FS 레이아웃을 최적화했다. 이를 통해 BSD 4.2의 FFS(고속 파일 시스템)가 탄생했다.[2][3]

BSD FFS는 관련된 데이터 블록과 메타데이터를 동일한 실린더 그룹에 배치하여 접근성을 높였다. 이상적으로는 디렉토리의 모든 내용(데이터 및 메타데이터)을 동일하거나 인접한 실린더 그룹에 위치시켜 디렉토리 내용이 전체 디스크에 분산될 때 발생하는 단편화를 줄이고자 했다.

수퍼블록에는 트랙 및 섹터 수, 디스크 회전 속도, 헤드 속도, 트랙 간 섹터 정렬 등 성능 관련 매개변수가 포함되었다. 완전히 최적화된 시스템에서는 플래터가 회전하는 동안 인접한 트랙 간에 헤드를 이동하여 교대로 트랙에서 분산된 섹터를 읽을 수 있었다.

그러나 디스크가 커지면서 섹터 수준 최적화는 효과를 잃게 되었다(특히 선형 섹터 번호 매기기와 트랙당 가변 섹터를 사용하는 디스크). 더 큰 디스크와 파일로 인해 조각난 읽기가 더 큰 문제가 되었다. 이를 해결하기 위해 BSD는 4.0 BSD에서 파일 시스템 블록 크기를 1섹터에서 1 K로 늘렸고, FFS에서는 1 K에서 8 K로 늘렸다. 이는 파일 섹터가 연속될 가능성을 높이고, 파일 블록 나열에 필요한 오버헤드를 줄이며, 주어진 블록 수로 나타낼 수 있는 바이트 수를 증가시키는 효과를 가져왔다.

최대 블록 수가 고정된 비트 폭 블록 번호로 제한되므로 더 큰 디스크 크기도 가능해졌다. 하지만 블록 크기가 커지면서 작은 파일이 많은 디스크는 각 파일이 최소 하나의 블록을 차지해야 하므로 공간 낭비가 발생했다. 이를 해결하기 위해 BSD는 여러 파일의 마지막 부분 블록 데이터를 여러 개의 비어 있는 블록 대신 단일 "조각" 블록에 저장하는 블록 하위 할당, 테일 병합 또는 테일 패킹이라고 하는 "블록 수준 단편화"를 추가했다.[4]

5. 2. 블록 크기 증가

BSD는 더 큰 디스크와 파일을 지원하기 위해 파일 시스템 블록 크기를 4.0 BSD에서 1섹터에서 1,000로 늘렸고, FFS에서는 1,000에서 8,000로 늘렸다. 이는 파일의 섹터가 연속될 가능성을 높이고, 파일의 블록을 나열하는 데 필요한 오버헤드를 줄이며, 주어진 수의 블록으로 더 큰 파일을 표현할 수 있게 한다.[4]

그러나 블록 크기가 커지면 많은 작은 파일을 가진 디스크는 각 파일이 최소한 하나의 블록을 차지해야 하므로 공간을 낭비하게 된다. 이를 해결하기 위해 BSD는 여러 파일의 마지막 부분 블록 데이터를 여러 개의 비어 있는 블록 대신 단일 "조각" 블록에 저장할 수 있는 블록 하위 할당(테일 병합 또는 테일 패킹이라고도 한다)을 추가했다.[4]

5. 3. 블록 하위 할당 (테일 패킹)

BSD는 블록 크기가 커짐에 따라 작은 파일이 많은 경우, 각 파일이 최소한 하나의 블록을 차지해야 하므로 발생하는 공간 낭비를 줄이기 위해 블록 하위 할당을 도입했다.[4] 블록 하위 할당은 여러 파일의 마지막 부분 블록 데이터를 여러 개의 비어 있는 블록 대신 단일 "조각" 블록에 저장하는 방식이다. 이를 테일 병합 또는 테일 패킹이라고도 한다.

6. 구현

UFS는 다양한 운영체제에서 구현되어 사용되고 있다.

SunOS / 솔라리스, SVR4, HP-UX, Tru64 UNIX와 같은 일부 독점 유닉스 시스템과 illumos와 같은 오픈 유닉스 파생 시스템이 UFS를 채택했다. 이들 대부분은 UFS를 자체 용도에 맞게 조정하여 독점적인 확장을 추가했기 때문에 다른 공급업체의 유닉스 버전에서는 인식되지 않을 수 있다. 하지만 많은 경우 원래 UFS와 같은 블록 크기 및 데이터 필드 너비를 계속 사용했기 때문에 플랫폼 간에 어느 정도의 읽기 호환성은 유지된다. 구현 간의 호환성은 불규칙하다.

Kirk McKusick은 파일 시스템의 블록을 쓰기 전에 다시 정렬하여 조각화를 줄이고 파일 시스템의 노후화를 제어하는 기술인 블록 재할당을 구현했다. 그는 또한 충돌이나 전원 오류 후 파일 시스템 검사 요구 사항을 줄이는 소프트 업데이트를 구현했다.

UFS2에서 Kirk McKusick과 Poul-Henning Kamp는 FreeBSD FFS 및 UFS 계층을 확장하여 64비트 블록 포인터(볼륨이 최대 8 제비바이트까지 증가 가능), 가변 크기 블록(익스텐트와 유사), 확장 플래그 필드, 추가 '생성 시간' 스탬프 등을 추가했다.

6. 1. BSD 계열

FreeBSD, NetBSD, OpenBSD, DragonFlyBSD 등 BSD 유닉스 시스템에서 파생된 UFS1 및 UFS2 구현은 두 계층으로 나뉜다. 상위 계층은 디렉터리 구조와 inode 구조의 메타데이터(권한, 소유권 등)를 지원하고, 하위 계층은 inode로 구현된 데이터 컨테이너를 제공한다. 이는 기존 FFS와 LFS 로그 구조 파일 시스템 모두 공통 기능을 위한 공유 코드를 사용하기 위해 수행되었다. 상위 계층은 "UFS", 하위 계층은 "FFS" 및 "LFS"라고 한다.

Kirk McKusick은 파일 시스템 블록을 쓰기 전에 다시 정렬하여 조각화를 줄이고 파일 시스템 노후화를 제어하는 기술인 블록 재할당을 구현했다. 그는 또한 충돌이나 전원 오류 후 파일 시스템 검사 요구 사항을 줄이는 소프트 업데이트를 구현했다.

UFS2에서 Kirk McKusick과 Poul-Henning Kamp는 FreeBSD FFS 및 UFS 계층을 확장하여 64비트 블록 포인터(볼륨 최대 8 제비바이트까지 증가), 가변 크기 블록(익스텐트와 유사), 확장 플래그 필드, 추가 '생성 시간' 스탬프, 확장 속성 지원 및 POSIX1.e ACL을 추가했다. UFS2는 FreeBSD 5.0부터 지원되는 UFS 버전이다. FreeBSD는 UFS1 및 UFS2 모두에 대해 소프트 업데이트와 파일 시스템 스냅샷을 만들 수 있는 기능을 도입했다. OpenBSD는 2.9 버전부터 소프트 업데이트를 지원했고,[6] 4.2 버전부터 UFS2(FFS2)를 지원했다.[8]

FreeBSD, NetBSD, OpenBSD, DragonFly BSD는 Ian Dowse가 개발한 Dirhash 시스템을 포함한다. Dirhash는 디렉터리 조회를 가속화하기 위해 메모리 내 해시 테이블을 유지 관리한다.

6. 2. 상업용 유닉스

SunOS / 솔라리스, SVR4, HP-UX, Tru64 UNIX와 같은 일부 상업용 유닉스 시스템 공급업체는 UFS를 채택했다. 이들 대부분은 UFS를 자체 용도에 맞게 조정하여 독점적인 확장을 추가했다. 많은 경우 원래 UFS와 같은 블록 크기 및 데이터 필드 너비를 계속 사용했기 때문에 플랫폼 간에 어느 정도의 읽기 호환성이 유지된다.[5]

썬 마이크로시스템즈는 Solaris 7부터 UFS 로깅을 포함했는데, 이는 파일 시스템 저널링을 UFS에 도입한 것이며 현재 버전의 Solaris에서도 사용할 수 있다.[5] Solaris UFS는 대용량 파일 및 대용량 디스크를 위한 확장 기능 등도 갖추고 있다.

6. 3. 리눅스

리눅스는 다른 유닉스와의 읽기 수준에서 바이너리 호환성을 위해 UFS를 구현하고 있지만, UFS에 대한 공급업체 확장에 대한 표준 구현이 없기 때문에 UFS에 대한 쓰기를 완벽하게 지원하지는 않는다.[11] 기본 리눅스 ext2 파일 시스템은 UFS1에서 영감을 받았다.

6. 4. macOS

애플(Apple Inc.)의 macOS에서는 HFS+의 대안으로 UFS를 사용할 수 있었지만, Mac OS X Leopard부터는 UFS 형식 볼륨에 Mac OS X를 설치할 수 없게 되었다. 또한 UFS 형식 볼륨에 설치된 이전 버전의 Mac OS X를 Leopard로 업그레이드하려면 시동 볼륨을 다시 포맷해야 했다.[10] Mac OS X에서 UFS로 포맷된 디스크에는 4 GB 파일 제한이 있었다. Mac OS X Lion부터 UFS 지원이 완전히 중단되었다.[11]

참조

[1] 웹사이트 '[base] Contents of /Head/Sys/Ufs/Ufs/Dinode.h' https://svnweb.freeb[...]
[2] 웹사이트 Open Sources: Voices from the Open Source Revolution https://www.oreilly.[...] 1999-03-29
[3] 간행물 A Fast File System for UNIX https://www.cs.corne[...] 2013-04-08
[4] 웹사이트 UFS2 and Soft Updates make for a powerful combination http://ws.edu.isoc.o[...] Network Startup Resource Center 2013-04-08
[5] 웹사이트 UFS Logging https://docs.oracle.[...] 2022-09-27
[6] 웹사이트 OpenBSD 2.9 Release http://www.openbsd.o[...] OpenBSD 2013-04-08
[7] 웹사이트 Soft updates disabled for future VFS work https://undeadly.org[...] OpenBSD_Journal 2024-03-09
[8] 웹사이트 OpenBSD 4.2 Release http://www.openbsd.o[...] OpenBSD 2013-04-08
[9] 웹사이트 Make FFS2 the default filesystem https://marc.info/?l[...] OpenBSD 2020-04-07
[10] 웹사이트 Archived — Mac OS X 10.5 Leopard: Installing on a UFS-formatted volume https://support.appl[...] Apple, Inc 2013-04-08
[11] 웹사이트 Lion won't mount any disk images with the built-in utility or Disk Utility https://discussions.[...] Apple, Inc 2013-12-24
[12] 뉴스 The OpenBSD 2.9 Release http://www.openbsd.o[...]
[13] 뉴스 The OpenBSD 4.2 Release http://www.openbsd.o[...]
[14] 문서 Mac OS X 10.5 Leopard: Installing on a UFS-formatted volume http://docs.info.app[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com